Originally, standalone desktop programmers were developed that took data from an operator, typically an engineer, and programmed it directly into a programmable electronic microdevice. The mechanism for inserting and removing the microdevice from the desktop programmer was an operator who manually performed the task. The desktop programmer could only put data into and take data out of a microdevice, and manipulate the data.
At the same time, there were companies that produced electronic microdevice labelers. These labelers contained a built-in printer and would take labeling information, print a label, and place the label on the microdevice. These systems were more automated. They could take an entire tube of microdevices and move the each microdevice though the system, labeling each microdevice and placing it back it an empty receiving tube. In this system, the operator only had to handle the tube of microdevices and not each microdevice itself. However this system could only label parts.
A business, which needed to program and label microdevices, bought two completely different systems from two different companies. Then, as two separate processes they would program all their microdevices and then label all their microdevices.
Subsequently, a system was created which merged the two systems. The idea was to have an automated system that would program and label parts together in one process. Not only did this reduce the number of steps in the user's process, but it also eliminated the need for the operator to physically touch the microdevice. Now the operator only needed to handle the tubes of microdevices, inserting and removing them from the machine. The machine now did all the microdevice-by-microdevice handling, programming and labeling.
One big problem, however, was the two systems had no idea how to talk to each other. They were not designed to work together or to know of the other's existence. One good point was each of the different systems had a remote control interface. Hence, a handling link program was created that used each systems' remote control interface to arbitrate process control between the two systems.
With this arrangement, there existed a handling link program separate from a programmer program which was separate from a labeler program. They talked to each other, but generally were developed separately, updated separately, and in some cases developed by different companies.
During the development of the concept of a programmer/feeder system, it became apparent that a remote, non-connected control system and program was desirable. Unfortunately, for many years the “legacy” systems, or traditional systems, such as standalone programmers, had only focused on microdevice programming, data manipulation, and self-test capabilities. This meant that many new operations would have to be performed in a new program which can control both a programmer in an integrated system and a standalone programmer, where an operator has to manually insert the microdevices.
The new program would have to use each systems' remote control interface to arbitrate process control between the systems. It would have to provide a complete user interface for entering and storing all microdevice handling, labeling, and programming information. When an operator selects the setup information it must be sent to each component in the system. The new program would then have to start arbitration while keeping each of the components working in synchronization during the process. It would have to keep track of statistic results for the operations being performed. Ideally, the setup information would be stored to be easily used over and over again to run the same microdevices. Further, the new program would ideally also provide a mode of operation where an operator could manually, one by one, enter each of the parameters for programming a batch of microdevices and then just initiate operation.
In addition, it was apparent that many businesses wanted to have the capability of minimizing operator skill and dividing the operation of the new program into different parts than anything which had been done in the past. In essence, an engineering (free form) style user interface and a manufacturing (automated) style user interface were desired in one product.
Thus, it was apparent that there would be many major problems in developing a programmer/feeder system program which could be controlled from a separate personal computer while still being able to control previously developed legacy programming, labeling, and handling systems, and the systems which would evolve from them.